Slim htsjdk's published runtime classpath by making the JavaScript
engine an opt-in dependency, and clean up around the change. Net effect
for consumers of the v5.0.0 artifact: 6 fewer jars on the runtime
classpath (nashorn-core + 5 ASM transitives, ~2.5 MB) and one less
"misleading direct dependency" in the published POM.

** BREAKING CHANGE **

Consumers using htsjdk.samtools.filter.JavascriptSamRecordFilter or
htsjdk.variant.variantcontext.filter.JavascriptVariantFilter must now
add a JSR-223 "js" engine to their own runtime classpath. The
recommended choice is OpenJDK Nashorn:

    Gradle:  runtimeOnly 'org.openjdk.nashorn:nashorn-core:15.7'

    Maven:   <dependency>
               <groupId>org.openjdk.nashorn</groupId>
               <artifactId>nashorn-core</artifactId>
               <version>15.7</version>
               <scope>runtime</scope>
             </dependency>

If no engine is on the classpath at runtime, AbstractJavascriptFilter's
constructor now throws a RuntimeScriptException whose message names the
calling filter class and prints both Gradle and Maven coordinates, so
the failure is fully self-describing.

** Changes **

build.gradle:
- Nashorn moved from `implementation` to `compileOnly` (and bumped
  15.4 -> 15.7). It also appears as `testImplementation` so the
  project's own test suite still has an engine available.
- Removed the direct `commons-logging:1.3.0` declaration. htsjdk does
  not use commons-logging itself; it was only declared to bump the
  version that commons-jexl 2.1.1 transitively pulls (1.1.1, from 2007).
  Replaced with a Gradle dependency constraint, so the published POM
  advertises the version pin in <dependencyManagement> rather than as
  a real direct dep. Same runtime behavior, more honest metadata.

src/main/java/htsjdk/samtools/filter/AbstractJavascriptFilter.java:
- Replaced the prior "Do you use the SUN/Oracle Java Runtime?" error
  with a multi-line, fully self-describing message via a new
  package-private noJsEngineMessage(String) helper.

src/main/java/htsjdk/samtools/filter/JavascriptSamRecordFilter.java
src/main/java/htsjdk/variant/variantcontext/filter/JavascriptVariantFilter.java:
- Class Javadoc rewritten with a clear summary, a small inline usage
  example, and a "Runtime requirement" callout pointing at the
  nashorn-core artifact coordinates.

Test changes (separate prep work, kept here so the entire JS-filter
surface lands in one PR):
- Deleted 4 checked-in JavaScript test fixtures
  (samFilter01.js, samFilter02.js, variantFilter01.js, variantFilter02.js).
- Rewrote both JavascriptSamRecordFilterTest and JavascriptVariantFilterTest
  as many small, focused tests using inline String scripts and
  programmatically-built SAMFileHeader / VCFHeader / SAMRecord /
  VariantContext fixtures. New coverage: all three constructors,
  return-type semantics (null/undefined/boolean/integer/double/string),
  bindings reachability for both `record`/`variant` and `header`,
  subclass record-key override (SAM), error paths (malformed JS,
  exception-throwing scripts), filterOut(first, second) AND-semantics
  (SAM), multi-record reuse, and one assertion that the no-engine
  error message stays actionable. 46 new test cases in total.

** Verification **
- ./gradlew test: 21,963 / 21,963 pass.
- ./gradlew dependencies --configuration runtimeClasspath: confirms
  nashorn-core and the 5 ASM artifacts are gone; commons-logging now
  shows under jexl as 1.1.1 -> 1.3.0 (transitive) plus a (c) constraint
  marker rather than as a top-level dep.

The breaking change will be called out in the dedicated v5.0.0
CHANGELOG / breaking-changes PR alongside the other v5.0.0 changes.